Industrial control systems have enabled modern factories to become partially or completely automated in many circumstances. These systems generally include a plurality of Input and Output (I/O) modules that interface at a device level to switches, contactors, relays and solenoids along with analog control to provide more complex functions such as Proportional, Integral and Derivative (PID) control. Communications have also been integrated within the systems, whereby many industrial controllers can communicate via network technologies such as Ethernet, Control Net, Device Net or other network protocols and also communicate to higher level computing systems. Generally, industrial controllers utilize the aforementioned technologies along with other technology to control, cooperate and communicate across multiple and diverse applications.
At the core of the industrial control system, is a logic processor such as a Programmable Logic Controller (PLC). Programmable Logic Controllers are programmed by systems designers to operate manufacturing processes via user-designed logic programs or user programs. The user programs are stored in memory and generally executed by the PLC in a sequential manner although instruction jumping, looping and interrupt routines, for example, are also common. Associated with the user program are a plurality of memory elements or variables that provide dynamics to PLC operations and programs. These variables can be user-defined and can be defined as bits, bytes, words, integers, floating point numbers, timers, counters and/or other data types to name but a few examples.
Industrial controllers and associated control systems have increasingly become more sophisticated and complicated as control applications have been distributed across the plant floor and in many cases across geographical or physical boundaries. As an example, multiple controllers and/or other devices may communicate and cooperate to control one or more aspects of an overall manufacturing process via a network, whereas other devices may be remotely located, yet still contribute to the same process. In other words, control applications have become less centrally located on a singular control system having associated responsibilities for an entire operation. Thus, distribution of the overall control function and/or process frequently occurs across many control components, systems or devices.
Current control and communications architectures for distributed control and services can include data servers that manage protocol level details, including server applications that deal with name parsing as well as device and network specifics. Many systems abstract these details into a common set of events that an application then must support. For example, current systems often pass items and active states down to the server application, wherein the server application is then responsible for keeping track of what items should be polled and the scheduling of the items. When the server application gets data, it can parse through a buffer and update new values for each item that is active. These values can then be checked against an old value, if the value is different, then data can be sent to the client. Client applications, such as a Human Machine Interfaces (HMI) or other type applications generally connect to the server (e.g., controller acting as a server) and employ specified interfaces to add and remove groups, add and remove items, receive subscriptions and perform reads and writes to an industrial controller, for example.
Unfortunately, the above server architecture is subject to several limitations. First, the above server applications often maintain multiple lists of items and associated states. Thus, these applications often expend valuable bandwidth processing the lists. As an example, some repeated operations can occur for every item on the list. Second, some distributed interfaces do not facilitate scaling up to many client machines. Some specifications enable clients to specify an item handle to notify clients that data has changed. Since this handle is unique for different instances of the client, this can cause servers to build a packet specific to the client and send it to that particular client application. If many clients are connected to a server application, the server might be building packets with the same data and with different item handles. This causes higher processing requirements on the server machine with increased network traffic and can limit the ultimate amount of scalability that a system can have.
A third problem with current architectures is the amount of modularity that is in an application. In many instances, a large application can talk to multiple devices on multiple networks. Thus, there is often no modularity with regards to loading components as they are needed to communicate to a specific device. Still yet another problem involves remote connections between applications. When clients and servers are remote, as in a distributed application scenario, if the connection is broken between machines, calls from clients to servers generally have to timeout before returning to the client—with the timeout often approaching 30 to 40 seconds. This can cause long delays in responsiveness of client applications. Once there has been a disconnection for example, there is generally no automatic reconnection and it is difficult or impossible to establish a given state before the connection between machines was lost.